What is an MVP? A plain-English guide to minimum viable products

An MVP, or minimum viable product, is the simplest working version of a product or software idea that you can put in front of real users. It includes only the features needed to test whether the core idea solves a real problem, nothing more.

The term comes from Eric Ries and the Lean Startup methodology, but it has moved well beyond the startup world. Established businesses use MVPs to validate new software features, internal tools, customer portals, and digital products before committing full development budgets to them.

This guide covers what an MVP actually is, how it differs from a prototype, when it makes sense to build one, and what the process looks like in practice. If you are considering commissioning a bespoke software build, the MVP question is almost always the right place to start.

What is an MVP?

An MVP is a working product, not a mockup or a wireframe. It does something. Users can interact with it, and their behaviour tells you whether your idea is worth developing further.

The 'minimum' part matters as much as the 'viable' part. You are not building a rough, unfinished thing. You are building a precisely scoped thing: the smallest version that still works, that still delivers genuine value, and that still generates real feedback. Cutting corners on the core feature defeats the purpose.

What it is not:

• Not a prototype: a prototype demonstrates a concept. An MVP is a working product that users can actually use.

• Not a beta: a beta is a nearly-complete product being tested for bugs. An MVP is a deliberately limited product being tested for viability.

• Not an excuse for poor quality: the features you do include must work properly. A broken MVP produces false data.

• Not always software: an MVP can be a manual process, a spreadsheet, or a concierge service. You build the automation once you know what to automate.

What does MVP stand for in business?

MVP stands for Minimum Viable Product.

In a business context, it refers to the practice of validating a product idea with real users before investing in full development. Rather than spending six months building a complete system based on assumptions, you build the core feature, test it, learn from real behaviour, and then decide whether to continue, change direction, or stop.

The business case is straightforward: most product ideas that seem sound in planning turn out to need significant changes once real users encounter them. An MVP surfaces those changes early, when they are cheap to make, rather than late, when they are expensive.

For established businesses considering new software, a customer portal, or a digital product, the MVP question is: what is the smallest version we could build that would tell us whether this is worth the full investment?

MVP examples: what they look like in practice

The most-cited MVP examples are instructive because they show how radically minimal a 'viable' product can be:

• Amazon (1994): Jeff Bezos launched as an online bookstore only, despite planning to sell everything. Books were the MVP: easy to ship, no spoilage, universal demand. The feedback from that narrow product informed every subsequent category expansion.

• Airbnb (2007): The founders rented out air mattresses in their own flat to conference attendees, manually handling everything. No platform, no payments system, no reviews. They needed to know whether strangers would pay to sleep in other strangers' homes. They would.

• Dropbox (2007): Before writing a line of code for the product, the founders made a three-minute video explaining what Dropbox would do. Overnight, the waiting list grew from 5,000 to 75,000. The MVP was a video, not software.

At 16i, we applied the same approach when working with PIPA, the UK's Inflatable Play Inspection Scheme. Rather than attempting to redevelop their entire certification platform in one go, we scoped the initial build around the core inspection reporting workflow: the one process that, if it failed, would stop the scheme from functioning. That gave PIPA a working, testable system for their inspectors to use in the field while the more complex features, including data comparison between inspection cycles, the adaptive user dashboard, and public certificate transparency, were validated and added in subsequent phases. The result was a platform that PIPA's team understood and trusted from the first release, rather than one delivered all at once after a long development period with no opportunity to course-correct.

When does building an MVP make sense?

An MVP is the right approach when two conditions are true: you are not certain the idea will work, and the cost of being wrong is significant. If both of those are true, the MVP reduces your exposure.

Specific situations where an MVP is the right starting point:

• New internal software: before replacing a legacy system that the whole business depends on, an MVP lets you test the replacement with a subset of users first.

• New customer-facing product: if you are launching a portal, app, or platform for customers, an MVP limits the risk of building the wrong thing at full scale.

• New feature on an existing platform: rather than committing a full development sprint to a new feature, an MVP version tests demand before full build-out.

• Uncertain requirements: if you cannot clearly define what the finished product needs to do because you do not yet understand how users will interact with it, an MVP is how you find out.

• Stakeholder buy-in needed: a working MVP is often more persuasive to a board or budget committee than a business case. Real data from real users is harder to argue with than projections.

An MVP is not always the answer. There are situations where it adds cost rather than reducing it:

• Compliance-critical systems: medical devices, financial trading platforms, and regulated systems cannot launch a 'minimum' version. Regulatory requirements demand completeness from the start.

• Network-effect products: a social network with ten users provides no value. Some products only work once they reach critical mass, making iterative validation impractical.

• When demand is already proven: if multiple successful competitors are doing the same thing, you do not need an MVP to prove demand. You need a better product.

MVP vs proof of concept: what is the difference?

•  

  Description

  Proof of concept

  Tests whether an idea is technically feasible. Usually internal, not shown to end users. Answers: can we build this?

  Prototype

  A non-functional or partially functional mockup used to visualise the product. Answers: does this feel right?

  MVP

  A working, deployable product with deliberately limited scope. Shown to real users. Answers: do people want this?

  Beta

  A near-complete product tested for bugs before launch. The idea is proven; the execution is being refined.

The key distinction between an MVP and a proof of concept is who uses it and what you learn. A proof of concept is typically internal and technical: it answers whether something is buildable. An MVP is external and commercial: it answers whether something is valuable to real users in real conditions.

How to scope an MVP: the questions that matter

The most common mistake in MVP scoping is adding too much. Every feature that gets added is a feature that takes longer to build, costs more to develop, and makes it harder to isolate which part of the product is working or not working.

These are the questions that keep an MVP genuinely minimal:

• What is the single core assumption this needs to test? Not three assumptions, one. What is the thing that, if it turns out to be wrong, changes everything?

• What is the minimum a user needs to do to generate that data? Map the user journey and then remove every step that is not essential to the test.

• How will you measure success? Define this before you build, not after. What does validation look like? What does failure look like?

• What is out of scope? Write the list of things you are deliberately not building. This prevents scope creep and keeps the team focused.

• Who are the users? An MVP shown to the wrong users produces misleading data. Define the specific user group carefully.

At 16i, our discovery process for bespoke software projects typically includes an MVP scoping phase before any code is written. The output is a clear brief that defines what is being built, what success looks like, and what is deliberately excluded from version one.

How long does an MVP take and what does it cost?

Both depend heavily on scope. An MVP for an internal workflow tool is a different undertaking from an MVP for a customer-facing platform with authentication, data storage, and third-party integrations.

As a rough guide:

• Type of MVP

  Typical range

  Simple internal tool or admin interface

  4 to 8 weeks / from 10,000 pounds

  Customer-facing portal or web application

  8 to 16 weeks / from 25,000 pounds

  Mobile application MVP

  12 to 20 weeks / from 40,000 pounds

  Complex platform with integrations

  Scoped individually after discovery

These figures assume a professional development team working in .NET or a comparable robust stack, with proper discovery, UX, build, QA, and deployment. An MVP built on no-code tools will be cheaper and faster to launch but will almost certainly need to be replaced when it hits the limits of the platform.

At 16i, we scope MVP phases during discovery rather than quoting upfront. The discovery conversation is what allows us to give you a realistic figure rather than a guess.

Frequently asked questions

What does MVP stand for?

MVP stands for Minimum Viable Product. It refers to the simplest working version of a product that can be tested with real users to validate whether the idea is worth developing further.

What is an MVP in business?

In a business context, an MVP is a way of testing a new product, software feature, or digital idea before committing a full development budget to it. Rather than building everything and hoping it works, you build the minimum necessary to generate real user feedback, then decide what to build next based on what you learn.

How is an MVP different from a prototype?

A prototype is typically non-functional or partially functional, used internally to visualise how a product might work. An MVP is a working, deployable product that real users can actually use. Prototypes generate opinions; MVPs generate behaviour data.

How much does it cost to build an MVP?

Costs range from around 10,000 pounds for a simple internal tool to 40,000 pounds or more for a customer-facing platform or mobile application. Complex projects with multiple integrations are scoped individually. At 16i, we establish a realistic figure during our discovery phase rather than quoting before we understand the scope.

Can an established business benefit from an MVP approach?

Yes. The MVP approach is not only for startups. Established businesses use it to validate new internal tools, customer portals, product features, and digital platforms before committing full development resource. The principle is the same: test the core assumption with the minimum viable build before investing in the full version.

Thinking about an MVP for your business?

16i is a B Corp-certified bespoke software development agency based in Cheltenham. We build MVPs, web applications, portals, and digital platforms in .NET; designed to be tested, iterated, and scaled. If you have an idea you want to validate before committing to a full build, our discovery process is designed to help you scope it correctly from the start. An initial conversation is free and no-obligation.

Read: What is bespoke software development?

Read: When does bespoke software development make sense?
See our bespoke software work